A really simple and adhoc POC of how a pattern block as a section element could be implemented. This PR introduces a new attribute to the core/pattern block: type. Currently, the only possible value is section.

The original pattern block

The implementation of the pattern block is relatively simple, it doesn't have a save function, and its edit function replaces itself with the registered pattern blocks by its slug. For instance, a pattern block like this:

<!-- wp:pattern {"slug":"twentytwentythree/footer-default"} /-->

...will transform itself into this when it's loaded in the editor (if it's registered):

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:group {"align":"wide","style":{"spacing":{"padding":{"top":"var:preset|spacing|40"}}},"layout":{"type":"flex","justifyContent":"space-between"}} -->
<div class="wp-block-group alignwide" style="padding-top:var(--wp--preset--spacing--40)"><!-- wp:site-title {"level":0} /-->

<!-- wp:paragraph {"align":"right"} -->
<p class="has-text-align-right">
		Proudly powered by <a href="https://wordpress.org" rel="nofollow">WordPress</a>		</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

Notice that the original wp:pattern block disappears and no longer exists.

However, this approach stops us from keeping the metadata of the block. We no longer know that the replaced blocks are from a "footer" pattern, nor the pattern is from the twentytwentythree theme.

A solution

One solution is to keep the wrapper pattern block when it's transformed, so that we won't lose any of the information. The pattern block will then behaves like a "group" block with semantic meaning.

It also doesn't do any transforming or replacing in its edit function, instead it simply renders the inner blocks if it's defined. It relies on the source to populate the inner blocks upon insertion, just like how a group block is implemented.

This PR changes how a pattern block is inserted from the global block inserter. Instead of sending just the slug attribute, it will now populate the inner blocks as well.

To maintain backward compatibility, the original behavior when no type attribute is specified is kept. So that template parts which rely on this behavior can continue to function
as before. It also implies different "syncing" behavior as this will always sync data from the registered patterns. We might also want to explore different syncing behavior for patterns with type: section too.

Note that this is not the final proposal but just a POC and an idea that we can play with in future iterations. Hope that a runnable branch could spark more ideas and feedback.

Testing Instructions

1. Insert a pattern block in the code editor by hand.
2. Exit the code editor, see that the pattern is inserted.
3. Go back to the code editor, see that the pattern block got replaced.
4. Insert a pattern from the global inserter
5. See that the pattern is inserted in the visual editor.
6. Go to the code editor, see that the wp:pattern block is still present, and with a type: section attribute.
7. Save the post and reload. See that the pattern block is still there.

Screenshots or screencast